<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Eclipse Platform Operation Participation</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body>
<h1>Eclipse Platform Operation Participation</h1>
<p>The purpose of this document is to present details of the solutions for the 
  operation participation scenarios presented in <a href="logical-support.html">Enabling 
  Logical Model Integration in the Eclipse Platform</a>.</p>
<h2>Physical to Logical</h2>
<p>In Eclipse, there can typically be many different model spaces. Many of these 
  can be considered layers on top of the Platform resource model, in the sense 
  that the elements that constitute a model are persisted in Platform resources. 
  When operations are launched from model elements or are performed by model tooling, 
  consistency of the model can be maintained. However, given the presence of multiple 
  models and multiple layers, it is always possible that operations are launched 
  from elsewhere (i.e. the tooling of other models) and are not aware of all the 
  models that could be affected. For instance, deleting a file from the Resource 
  Navigator may corrupt a higher level model that was persisted, at least partially, 
  in that file. In this case, all the model tooling can do is make a best effort 
  at cleaning up and notify the user of any inconsistencies that may exist.</p>
<p>It would be beneficial if model tooling could participate in operations that 
  could potentially corrupt a model. This participation could take many forms:</p>
<ul>
  <li>receive pre-notification of an operation that is about to be performed 
    <ul>
      <li>notify the user that an operation they are performing may corrupt a 
        model</li>
      <li>abort an operation that would be too destructive</li>
    </ul>
  </li>
  <li>participate in the operation itself
    <ul>
      <li>augment the operation is such a way that model consistency is maintained</li>
    </ul>
  </li>
  <li>perform post-operation processing to adjust the model to the change</li>
</ul>
<p>There are several complicating factors:</p>
<ol>
  <li>The set of resource operations that can corrupt a model needs to be identified. 
  </li>
  <ul>
    <li>setting file contents and moving or deleting files/folders definitely 
      may corrupt a model</li>
    <li>what about creating or copying resources?</li>
    <li>project close</li>
  </ul>
  <li>At what level should the participation take place.</li>
  <ul>
    <li>Higher levels provide more context but are more numerous. Basically, each 
      layer would need to provide a participation API for higher layers to use.</li>
    <li>Lower levels are fewer but may not give the entire context of the operation 
      (or may not have direct access to a UI context)</li>
    <li>Even if higher level participation is supported, you would want lower 
      level hooks 
      <ul>
        <li>in case some tooling doesn't provide participation</li>
        <li>two independent models are built on the same resource (although this 
          seems unlikely to occur)</li>
      </ul>
    </li>
  </ul>
  <li>There may be multiple models interested in a single resource. 
    <ul>
      <li>Determining which models are interested must be efficiently computed. 
      </li>
      <li>The case of multiple interested parties, although potentially rare, 
        needs to be handled in a reasonable way</li>
    </ul>
  </li>
  <li>Augmenting an operation may result in further operations that again need 
    to go through the participation process</li>
</ol>
<p>&nbsp;</p>
<h2>Status</h2>
<p>Here is the status of this work as of 3.1 M5</p>
<ul>
  <li>Generic Views: This needs to be driven by model owners with help from Platform 
    committers. Until model teams step forward and dedicate resources to this 
    problem, it is unlikely that work will progress.</li>
  <li>ResourceMapping/ResourceMappingContext: Initial cut is available in 3.1 
    M5 and will be in 3.1 as provisional API.</li>
  <li>Merge Support: Although work has not begun, this area is well bounded and 
    well understood. </li>
  <li>Physical to Logical: This area is not yet well understood or well bounded 
    as participation in operations can happen at multiple levels and involve multiple 
    models. More design work is required before a solution can be proposed.</li>
</ul>
<h2>Open Issues</h2>
<p>Here are the list of open issues:</p>
<ul>
  <li><strong>Transaction support</strong>: Some repository may have transaction 
    support. It is unclear how this fits in with logical model support.</li>
</ul>
<p>&nbsp;</p>
</body>
</html>
